vimfandomcom-20200223-history
User talk:JohnBeckett/Archive3
This is an archive – please don't edit. Script-# pages My assumption is that vim.org provided direct links to vim.wikia.com/wiki/Script-# for commenting so going and marking all of them for deletion is sort of pointless. Go take a look at the new vim.org script pages. All of them have Vim Wiki links pointing to the associated Script-# page. --Preceding unsigned comment added by 38.97.88.20 21:19, February 10, 2010 :Thanks for the information. No one had told me that vim.org/scripts has recently been changed to include a link to non-existent pages on this wiki. For anyone reading this, if you look at you will see that there is a bar at the top saying: ::script karma Rating 13/9, Downloaded by 278 Comments, bugs, improvements Vim wiki :The "Comments, bugs, improvements Vim wiki" text is very new. Bram must have added it as a "give this a go" trial following this vim_dev thread. Actually, on re-reading that thread, I see that Bram said "There, I added a link in the header. Let me know if this will work." – I had not understood what he meant by that. :I'll think about this, and I'm certainly happy to try any experiment. However, it is extremely likely that these crap pages will just contain duplicated text (confusion) and unmaintained comments (quickly obsolete). Unfortunately, there is a fundamental conflict between the tidy mind of a fussy person (me) who wants to clean up the wiki, and the addition of pages with random noise that conflict with our procedures. However, I will leave the pages for the time being, and give them a chance to develop. :One possibility would be to make another wiki (vim-scripts.wikia.com). I would be happy to set it up and monitor it for spam. JohnBeckett 22:31, February 10, 2010 (UTC) ---- I like the idea of having a separate namespace for script pages. I don't want to see a bunch of poorly maintained script pages when I search for something in the tips. I think we could create a second search box, and have a "search tips" search box and a "search scripts" box. I liked your idea of having collections of scripts in a few pages, but I think that could get very hard to maintain, and the pages could get very large. I think Bram likes the idea of having a link on each script to the wiki page for that script, as well. It would be easier to add a new namespace for the scripts and update one word in the link, than to create a category system on vim.org that is mirrored by our script collection pages here. As far as maintaining the script pages goes, you and I could mostly try to control the spam. We could create a template that warns that the user should check the vim.org script page and release notes, that the wiki page may be out of date, and rely on the script authors to check/clean up the comments. This template would also, of course, link back to the vim.org page. I'm not sure if we'd want to, but it may be a good idea (once a lot of scripts have pages) to provide a link in our template, but I'm not sure of the best way to do that. Maybe it's better to just have the template link to the script itself, and then the user can see the comments by following another link back to the wiki. Anyway, those are my (somewhat disconnected) thoughts. We'll see how it goes. --Fritzophrenic 15:16, February 11, 2010 (UTC) :I agree that a Scripts namespace would be a good idea. That would keep all the information in one place, but the Scripts namespace could be elided from searches by default. Individual users could change their search preferences to include the Scripts namespace if they always wanted to search both tips and scripts. Otherwise, they can search using the the "Search Scripts" search box (if it can be added). :--JamesVega 17:01, February 11, 2010 (UTC) ::Thanks for the comments. Bear in mind that we do not have to accept these pages, and that they definitely will contain confusing, conflicting, out-of-date junk. Nevertheless, I suppose that in an optimistic spirit we could try this as an experiment. ::The namespace would be Script: (singular); for example, Script:123 would be the page for script 123. ::It would be nice to also get rid of all the pages like VimTip123 and move them to the Tip: newspace, for example Tip:123 but I suppose we couldn't really delete the VimTip pages now that people have got used to them. ::I'll probably contact Wikia soon and ask for the Script namespace. After a bit of testing, I'll ask Bram to change vim.org/scripts so it links to the new namespace, and will set up a template. JohnBeckett 10:05, February 12, 2010 (UTC) I find myself wondering if we'd be better off not applying our usual "avoid the talk pages" argument to script pages. The main page could be for a brief description, links, user comments, etc. with discussions of bug reports, feature requests, or similar on the talk pages. Or leave that for the author to decide. Thoughts? --Fritzophrenic 04:46, February 14, 2010 (UTC) This is probably far into the future if at all but I'd much rather have vim.org itself be a MediaWiki system or at least have MediaWiki functionality in script pages at vim.org. Currently, vim.org doesn't let you do much in a script description. There is limited linking, no formatting, no image uploads (e.g. for screenshots), and no headings other than description and install details. --Mortonfox 05:28, February 14, 2010 (UTC) :Fritzophrenic: Yes, I agree, and in fact it was my choice when asking Wikia for the Script namespace to ask that Script_talk also be created. Also, I do not want to hinder people from experimenting while the Script pages settle down and a standard operating procedure develops. I created a bunch of prescriptive text but in fact I'm a lot more relaxed than it sounds. Given the hint I guess I'll keep the talk page in question, but in general my understanding is that Script:1234 is a place for anyone to discuss script 1234, rather than a place to document it (and I guess Bram's "Comments, bugs, improvements" text describing the link to the wiki suggests that was what was on his mind, particularly since Bram created the link following a complaint that there was no way for users to provide feedback on vim.org, apart from the unhelpful rating system). Let's just see how it goes, but I really do not want authors to come here and just dump a copy/paste of their standard text because that is totally unhelpful to readers (I hate it when I find two sets of documentation particularly when they inevitably diverge). :Mortonfox: There is talk of vim.org being developed, but my confident hunch is that it will not happen. Bram simply has to maintain control of the site, and he has a lot better things to do than study changes proposed by random people to the vim.org PHP code – changes which would not result in anything significantly better than what he did by linking to here and making it our problem. JohnBeckett 07:04, February 14, 2010 (UTC) Update Bram has updated vim.org/scripts and script 1234 now links to Script:1234. I have moved all Script-xxxx pages to the correct location (matching the links on vim.org/scripts). Later (perhaps in a month or so) we can think about whether the template shown at the top of each script page, and the guideline linked to from the template, need tweaking. If anyone wants to add Template:ScriptComments to a new page, I tried to put the descriptive text in a standard format: scriptname: brief what it does (no space before colon; no period at end; all lowercase except for proper names and I retained the author's spelling of scriptname). Often I just took the text from the top of the vim.org/scripts page, but I omitted smilies and other extraneous words, and I changed the tense ("emulating ..." became "emulate ..."). JohnBeckett 01:50, February 15, 2010 (UTC) Page moved Hi John, As you may have seen, I just corrected two typos in the title of a page you recently edited (and I didn't see them both at once, so it resulted in two moves, happily with the history). I think I've taken care of "what links here" but you may want to check, and then remove (or not) the following redirects: * Using Vim for WYSIWIG editing of graphics through syntax highlightning * Using Vim for WYSIWIG editing of graphics through syntax highlighting Best regards, Tony Tonymec 14:33, March 21, 2010 (UTC) :Hi Tony. I'm hoping to restart consideration of the "new tips" soon, but I usually leave working out a good title until the tip is in its final form (because sometimes a tip gets refactored quite a lot and the original title is no longer appropriate). Also, I have messed up page moves, and I find it much better to plan new titles on the appropriate monthly new tips page (and see if there are any comments). You might like to comment at Vim Tips Wiki:New tips/200908. JohnBeckett 00:26, March 22, 2010 (UTC) ::Yeah, sorry, I didn't (this time) scroll down on the "New tips" page to where you warned about not changing the title until the "right" final title was agreed on. :") I guess you and I are "fussy" about different things (me, there are times when I want to fire my daily paper's copy editor for the number of spelling errors (s)he lets through). — Tonymec 03:12, March 22, 2010 (UTC) "Vim Tips"? Ha! Hey John, before I get all ranty, let me first thank you for all the work you're putting into gardening the vim tips content. I appreciate it. That said, I'm pretty turned off by the way tips appear to be getting handled. For starters, the fact that many of the old tips seem to be AWOL here doesn't do much for the claim that this is a replacement for the old vim tips site. But, more importantly, the way new tips appear to be getting handled has me seriously concerned that what used to be a thriving and interesting community of tip development may end up going away. Having just submitted a tip of my own, ( http://vim.wikia.com/index.php?title=Improved_Javascript_Indent_script_for_Vim ), what's the first thing that happens? Your bot comes along and slaps a big banner on the top that says, "please do not comment or discuss this tip". Greeaat. So in other words you're telling anyone who might be interested in giving me feedback on the quality of my tip to piss off. Thanks for nothing. :( To make matters worse your comment that, "tips like this are difficult for the wiki" just astounds me. Really, the "Vim Tips Wiki" has a hard time dealing with tips??? Fail. Finally, please note by aggregating all of the discussion on new tips onto a single page, you may be making your job easier, but you're also forcing new tip authors to sign up for change notifications on a page that will have a lot of discussion they really just don't care about. In other words, they ain't going to participate. You need to seriously reconsider this strategy! Discussion about tip suitability needs to take place on the tip's page. Sorry to be so crabby, but it's really frustrating to want to contribute something to a community that is (or was) a really great resource for me in the past, only to discover that it's at risk of drying up because of how it's being managed. Broofa 13:41, March 30, 2010 (UTC) ---- Hi, Broofa! I'm really sorry you're getting discouraged, I hope we can address your concerns. First, even though it has never worked this way, the discussion of whether or not to keep a new tip is intended to take place immediately during the month after a tip is entered, so you should not be seeing a tip remaining in the "proposed" state for several months as we see currently. But even if this is the case, your other concerns may be valid. It appears that the "proposed tip" banner needs some clarification. We do NOT want to discourage discussion of the tip content with this banner. Rather, we want to point users to the new tips discussion page to discuss whether or not to keep the tip as-is, merge the content into another tip, or do something else with it. THIS is the discussion which we want kept to a common location. Just as deleting a tip is supposed to be discussed in Category_talk:Candidates for deletion, we have a procedure to discuss new tips before they are "officially" added and get a tip ID. So far, it seems to have worked rather well, as looking at dozens of pages and checking them for changes to determine consensus for what to do with a new tip would be even harder for wiki maintainers as subscribing to one additional page would be for tip authors. That being said, apparently this has failed a bit in your case. Perhaps, it would be a good policy, once a consensus has been reached, to post the pending action to the tip itself and the author's talk page for a couple of weeks before implementing the change (unless the consensus is "keep", it which case we can just keep it). This may be a nice compromise. What do both of you think? Unfortunately here (as on wikipedia) policy is usually decided by a very small number of people and then applied with agreement from everyone initially involved...but sometimes not from everyone affected. As for the tip content itself, when John said "tips like this are difficult for the wiki," I believe he meant something along these lines: We want tips on the wiki to be both useful (which your tip is) and informative (which it lacks). To be both useful and informative, any scripts (especially large and/or complex ones) should be well documented both in comments, and with a description of what the script is doing, what problem it is solving, how it addresses the problem, etc. While a drop-in script can be useful, the vim.org scripts page is a more appropriate means of distribution for it. On the wiki, a script is more useful if interesting portions are brought to the user's attention, the design/thought process behind the script is described, or other things are done to make it so that the user, after reading the tip, knows how the script works and may even be able to duplicate the effort later on. Granted, many tips on the wiki fall short of these lofty goals. Even some well-established and heavily maintained tips like our CSV tip are script-heavy with little explanation. Nevertheless, we like to follow the "teach a man to fish" philosophy when creating new tips. I do not think your tip is a complete loss. I just think it needs a little work. If you are dedicated enough to putting the work in, I doubt we'd turn it down. However, please do consider that perhaps a plugin page (which can be discussed on the wiki with the new "Script:" namespace) or even an officially distributed indent plugin may be a better way to give your script to other Vim users. --Fritzophrenic 17:16, March 30, 2010 (UTC) ---- Oh, and regarding deleted tips previously on the old vim.org tips page. John, I thought we were redirecting or linking or using some other method to direct users to the place where the old content was "merged" even if it's really just a replacement and not a real merge? I understood that, unless the old tip was completely unuseful or just spam, that we had a method in place to not have such things fail? --Fritzophrenic 17:25, March 30, 2010 (UTC) Hi Fritz', thanks for the detailed reply. I appreciate your desire for keeping things structured and well-tended to. However, I think it may interfere with the broader goal of providing a useful community resource. I (and many others) would much rather have lots of half-baked tips with rich commentar about how the tips do/don't work .vs. a few well-structured tips with little if any commentary. That's the difference I'm currently seeing here, and that has me worried about the viability of this site. Perhaps, it would be a good policy, once a consensus has been reached, to post the pending action to the tip itself and the author's talk page for a couple of weeks before implementing the change (unless the consensus is "keep", it which case we can just keep it) Wouldn't it be better for the author to be part of that concensus discussion? (Your answer had better be, "yes!", btw. :-) ) Creating a tip is a non-trivial amount of work. To unilaterally decide to remove a tip w/out discussing that with the author is going to piss them off and just discourage any further contributions. That's why I find the centralized-page concept so distasteful. By making it difficult for authors to monitor the discussion around their tip, not only do you discourage improvement, you also alienate them from important discussions they should be part of, discussions that are important to keeping them engaged as productive contributers to the site. Regarding tips going AWOL - I may have misunderstood which content did/did not get migrated. I guess the vim.org/scripts/* stuff doesn't qualify as "tips"? Is that right? Anyhow, in general, I'd encourage you to loosen up and err on the side of allowing too much clutter into the site, rather than too little. E.g. The "Proposed new tip" banner shouldn't be red, it should be green. And the verbiage should say something like, "Help us improve this tip by adding comments to the discussion page. If this tip is not useful, or inappropriate, please add a comment to the discussion page and flag it with (DeleteCandidate tag)" Then, rather than having JohnBot leave little "do not use this page" turds on all new tips, have it update the DeleteCandidate list page where you can track which tips are/aren't flagged for deletion. Note, too, this will leave a better paper trail on the tip as to why it was/was not considered for deletion, and avoid repetitive discussion over time. That's my $.02. Hope it helps, and my apologies for being a bit pissy earlier. :) Broofa 18:16, March 30, 2010 (UTC) ---- Fritzophrenic: My understanding was that "deleted" tips were replaced by a redirect page, resending to whatever the deleted tip had be replaced by or merged into? Broofa: One of the problems of this wiki is that it has too few admins compared to the number of users. So for instance I have a tip about Cscope which is sitting here since November, waiting for the "Proposed new tip" banner to be taken off. In the meantime I've already incorporated a few useful comments into the body text, and mentioned it a few times on the mailing list to people to whom I thought it could be useful. For the rest... let's keep the Zen attitude: our lives are but a moment in eternity, let's not jump up in rage for mere trifles. And indeed, as Fritzophrenic said, and as you would have understood had you read the banner through, the New Tips page is for discussion about whether to keep or kill the new tip, but comments about the tip's content should go at the bottom of the tip's own page. May peace be with you. — Oh, and BTW when I look at that banner I don't see it as bright red but as a pale shade of pink, reminiscent of Valentine's Day. I'd rather have that than some greenish-decay-blerh colour. But of course YMMV. (Just my 0,02€.) — Tonymec 18:50, March 30, 2010 (UTC) ---- I would love to have authors engage in the discussion as to whether or not a tip is to be kept. This would of course be the point of posting to the tip itself and the author page with the consensus...to provide a "last chance" of sorts for the author to say "Hold on a minute, what are you doing?!". The note that John left you on the tip is actually our way of encouraging you to participate in this discussion...perhaps that should have been made more clear. For the sake of easier discussion, here is the comment John left: :We will discuss this at 201003, but that may take a while so I want to indicate now that tips like this are difficult for the wiki, although we do have another example (JavaFX indent plugin) that was put here specifically to get feedback. If a plugin has a problem, the author should be notified to fix it. A quick look at vim72/indent/javascript.vim indicates there is no official plugin, so if this tip has a working solution, it should be sent to Bram (after testing). Perhaps post on the vim_use mailing list to alert people to help with testing? In general, I agree with this idea. If there is no current "official" indent plugin for javascript, why not just send it to vim_use/Bram for testing and eventual distribution with the official Vim runtime? Or, why not send this to the maintainer of the plugin you mention as a suggestion to improve his plugin? Or upload this script by itself? In this specific case, if you think that your script has informative value, or have no ability/desire to maintain a "real" plugin, there may be good reasons to keep it here. Is the "we will discuss this..." line not clear enough? Note that the March 2010 new tips are, as of now, not open for discussion on the new tips page. It is not immediately obvious where to discuss the tip in the meantime, in general we use the "comments" section of a tip for that if anyone has feelings one way or another before the discussion opens on the new tips page as in this case. You are correct that the "Script:" pages do not qualify as "tips", they are more of a discussion forum for scripts on vim.org. If instead of a tip, you desire this page to be a place to get feedback on a script, then we do have a few examples of where that has been done in the past, but in general as a temporary thing prior to inclusion in a "real" script or plugin. You mention that you like the "rich commentary" on the old tips website. This is why we have established the "Comments" section on each tip instead of using the talk pages. We feel that it makes it easier to find all relevant information in a tip if everything is on one page. We leave comments sections even when empty to encourage comments from people who are less comfortable about editing the tip itself. But, once we have a comment pointing out a flaw in a tip, why leave the broken tip with a separate comment, when we could just take the comment and incorporate it into the original tip? This way, you get something immediately useful without wading through all the comments to make sure you're not missing any bug fixes. This is one of the main reasons we migrated to a wiki to begin with. As for making it difficult to see the relevant discussion on a tip's fate, perhaps (especially considering the currently long turnaround for discussing tip fates) it would be polite to mention when discussion begins. I think I will begin doing this but I don't know that we will make a regular policy of it, since we already have the "proposed tip" banner pointing out where the discussion will occur. By the way, I know from experience at Wikipedia how annoying it is when your hard work is just deleted without you getting any say because some wiki maintainer decided they didn't like what you did but couldn't bother telling you. I don't want to see that happen here. In the past, authors have taken part in the discussion on the new tips pages, so I thought it was working fine. --Fritzophrenic 20:07, March 30, 2010 (UTC) ---- @Broofa: Thanks for your feedback. I see what you mean about the Template:TipProposed box, and I have edited it with what I hope is better text and appearance. I do not quite agree with your interpretation of the old wording (which was not intended to suggest that the tip should not be discussed). Anyway, that's history – please let me know what you think of the new box. As Fritzophrenic mentioned, only vim.org/tips was imported to here (not vim.org/scripts). Quite a lot of the old tips have been merged or refactored, and this wiki was not intended as a mirror of the former vim.org/tips site. Several people have helped, and while some old tips were simply deleted as unhelpful, we have done a pretty good job of keeping nearly all useful ideas. The expectation was that vim.org/tips would continue indefinitely as a read-only repository of the old tips, so originally we did not go to much trouble to maintain all the old navigation (instead, the VimTip page for a removed tip just gave a link to the original tip on vim.org). After a crash, Bram found he could not recover the old tips (database corruption in backup?), and he decided to remove the old tips from vim.org. Since then we have been more careful to maintain incoming links to show where the new information resides. When merging tips in the last couple of months, I have been simply replacing old titles with a redirect to the new destination. For example, from 200908, the proposed tip Disable blinking cursor has been merged to Configuring the cursor (and the former is a redirect to the latter). I'm sorry my message at Improved Javascript Indent script for Vim#Comments was brusque, but it would take quite a long time to explain all the issues, and we often have had people create a page and then not return (so detailed explanations may go unread). In addition to Fritzophrenic's remarks about a central "new tips" discussion page, a useful feature of such a page is that it provides an easily-accessed record of what has happened each month. Of course that is mainly of interest to maintainers, but it may be useful to others who wonder what has happened to the new tips added in a particular month. When we were reasonably up to date in handling proposed new tips, I just deleted tips that we decided we did not want. Now (and particularly from Fritzophrenic's suggestion), I have been trying hard to keep the old title as a redirect to a tip containing the merged information, or a tip that covers the same information. I have left comments on proposed new tips that were destined for removal in order to alert the author if they were watching only that page (my comment on Improved Javascript Indent script for Vim is not an example of such an alert). It would be great if Broofa chooses to stay and help with the wiki – there are still plenty of old tips that need cleaning! JohnBeckett 07:03, March 31, 2010 (UTC) John, the new tip box is much better. Much more inviting. Thanks! (although... what should a discussion page be used for, if anything?) John said: It would be great if Broofa chooses to stay and help with the wiki Sure, I'd like that too. Buy my sense is that Vim Tips isn't really set up to engage people like me - so-called "drive by" contributors - who have very limited time/energy to engage a community. The old tips site was really easy to drop in on, throw down a tip, and move on. Nobody really cared how a tip was managed and nurtured. There was a basic rating and comment system that users could use to indicate which tips were genuinely useful to them and which weren't. All very low effort to set up and maintain. Can you really say that about this wiki? I mean, really. Look at the process overhead that's been introduced. There's apparently all this discussion and decision making that needs to go on to decide which tips are proposed, which are approved, and which should be deleted. Worse (from my perspective), that process isn't designed to make my life easy - it's designed around the convenience of the admins. I know this all sounds lazy and ungrateful, but I suspect it's pretty representative of a lot of people that used to contribute to the old vim tips site. Anyhow... just something for you to think about. Fritzophrenic said: In general, I agree with this idea. If there is no current "official" indent plugin for javascript, why not just send it to vim_use/Bram for testing and eventual distribution with the official Vim runtime? # 'Not sure how best to go about doing that, or how much time/energy that conversation will involve. # I have no idea if my script is polished enough to be included in the Vim distro. E.g. I suspect there's probably a more robust cindent-based approach that I just don't have time to figure out. In short, "'works for me, might work for others, but I wholly expect people to tell me about all the ways it doesn't work"... which is why I posted it here. # I don't know what time commitment being the official maintainer involves, and I'd like to get a sense of whether or not this script is actually useful before jumping into those waters. --Broofa 14:24, March 31, 2010 (UTC) How recently is «newly created» for a tip? Hi John. Don't you think Getting the Vim source with Mercurial (created 2010-05-14) could lose its «newly created tip» banner? (I guess it ought to have lost it so long ago that you forgot it hadn't) :-) Tonymec 02:31, April 15, 2011 (UTC) :Yes, it's been far too long! However, please bear with me for another week as it is likely that we will soon make progress at cleaning Vim Tips Wiki:New tips: a quick check shows that there is very little remaining to do in order to process everything up to and including May 2010. JohnBeckett 04:53, April 16, 2011 (UTC)